-
Notifications
You must be signed in to change notification settings - Fork 69
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add default value for signature algorithm #221
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for this! The patch is generally really good, I just left a few doc comment notes and an ask for more tests.
extensions: Certificate.Extensions {}, | ||
issuerPrivateKey: privateKey | ||
) | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know it's a bit of a chore, but can we get equivalent tests for the CMS and CSR use-cases as well?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's done. One test is currently failing, but that should be addressed by #220.
Contrary to RSA and ECDSA that take a SHA digest of the message as their input, Ed25519 uses the original message when computing the signature. For this reason, no digest algorithm was previously defined for the Ed25519 signature algorithm. However CMS requires a digest algorithm to be present in the SignerInfo. Therefore creating a CMS signature using a Ed25519 private key would previously fail. Per RFC 8419 section 2.3, "When signing with Ed25519, the message digest algorithm MUST be SHA-512". AlgorithmIdentifier.init(digestAlgorithmFor:) has been updated accordingly. Signature operations have been updated to delegate the validation of the signature algorithm and the computation of the message digest (when relevant) to the underlying key.
bfb155e
to
6bbb4fb
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very nice, this looks great.
Looks like there's a few format issues to fix up. |
OK, I've finally added |
Hah, sorry for that! The pain points of automation I suppose. |
Looks like we have some test failures here. |
Most of the time, the signature algorithm that should be used is dictated by the type of the private key. * Ed25519 keys support only one signature algorithm. * RFC 5753 section 8 recommends that "[the P-256 curve] be used with SHA-256; the P-384 curve be used with SHA-384; and the P-521 curve be used with SHA-512". * RSA keys support 4 signature algorithms. But most people use RSA with SHA-256 and nobody should use RSA with SHA-1 anymore. More over, Certificate.PrivateKey is opaque to the user, who may not know what type of private key they're using and what the appropriate signature algorithm is. For those reasons, we add convenience wrappers around methods with a signature algorithm to provide a reasonable default value.
That's the problem of putting my commits in independent PRs: CMS signature with Ed25519 doesn't work (yet). 😅 I've rebased on top of #220. This fixes the tests. |
Head branch was pushed to by a user without write access
849158f
to
8f8ee07
Compare
Most of the time, the signature algorithm that should be used is dictated by the type of the private key.
More over, Certificate.PrivateKey is opaque to the user, who may not know what type of private key they're using and what the appropriate signature algorithm is.
For those reasons, we add convenience wrappers around methods with a signature algorithm to provide a reasonable default value.